-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-1853 - HD Stake Pool Cold Keys #56
CIP-1853 - HD Stake Pool Cold Keys #56
Conversation
30ced0f
to
550804a
Compare
CIP-1853/CIP-1853.md
Outdated
|
||
Example: `m / 1853' / 1815' / 0 / 0'` | ||
|
||
Here the `usecase` is currently fixed to `0`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree in the future some use-cases may want to be soft-derived.
I'm not sure if there is any reason to have this specific use case be soft-derived instead of hard-derived though. given all child keys are hard-derived.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable. I think the use case field should be hardened, as discussed in the editors meeting.
For future extensions, for new sufficiently different schemes, we can simply use new values of the purpose field. This avoids complication in the use case being harded for some and non-hardened for others. Hardened is the safe default that works for the current SPO use case, and perhaps other similar future miscellaneous independent keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merging as per 1/26 meeting.
Creating this PR to have a wider discussion and standardize how should the stake pool cold keys be deterministically derived, to e.g. allow their management on hardware wallets
Not sure if right now there are other, possibly not yet published, CIPs that are meant to have this number as a follow-up of CIP-1852, but if they don't introduce a new derivation path purpose, it IMHO makes sense to have 1853 for this CIP which does so